In networks, it is desirable to measure packet traffic coming into and going out of a network device. Networking devices, such as switches and routers, examine packets to determine how to forward the packets. The forwarding process requires packet processing, such as developing forwarding rules, security policies, as well as Quality of Service (QoS) policies, such as bandwidth metering.
The packet processing mentioned above is typically expensive, particularly if the packets are processed while coming into (ingress) or leaving from (egress) a network device. As known in the art, some network devices are able to measure incoming packet traffic, some network devices are able to measure outgoing packet traffic, and other network devices are able to measure both. However, these network devices leave much to be desired, either in terms of limited finctionality or in terms of undue operating/processing costs. Typically, network devices that are able to monitor both input and output packet traffic are unduly expensive, particularly in terms of hardware and process time. For example, tracking both ingress and egress packet traffic requires processing the packets multiple times, which is cost prohibitive. As such, to manage operating costs, network operators are often forced to use network devices that only process ingress traffic. However, in several applications it is highly desirable to meter egress packet traffic. That is, some egress processing is particularly desirable but cannot be otherwise accomplished on the ingress side of a network device.
By way of example, egress rate metering cannot effectively be performed on the ingress side of a network device, especially in a multi-chip implementation (e.g., a chassis switch). Specifically, egress rate metering cannot be performed on the ingress side of a device because each ingress chip is unaware of the processes performed by every other ingress chip. In similar fashion, in a purely egress-based solution, each egress chip would be unaware of the processes performed by every other egress chip. Accordingly, implementing a shared egress meter (e.g., metering the total bandwidth of a trunk which spans multiple chips) doesn't work in either environment.
To date, attempts to obviate the limitations described above generally include network devices that either perform packet-processing only during packet ingress, perform packet processing only during egress, or perform packet-processing during both ingress and egress. Network devices that perform packet-processing only during ingress are capable of mimicking some egress-type processing functionality by replicating logic on ingress. However, this approach leaves much to be desired as some functions, such as output metering with multiple chips, cannot be accomplished by this type of ingress processing alone. Further, network devices that perform egress packet processing only, e.g., hubs and shared-backplane switches, are generally unfavored. This is largely a result of the requirement that for such implementations, every ingress packet must be seen by every egress device in order to be processed. Accordingly, the required interconnect bandwidth quickly becomes cost prohibitive. Network devices that perform packet-processing during both ingress and egress are typically implemented as high-end devices that require separate, dedicated chips for each of ingress processing and egress processing and are likewise excessively expensive. Finally, it should be appreciated that attempts have been made that involve metering each port of each network device. However, these solutions typically lack packet processing functionality and cannot handle multi-chip output architectures.